Les principes de l'Agilité

J.-M. Bruel
jbruel@gmail.com
version 1.0 2017-09-13

Pour suivre en live…​

 

Cette partie du cours est fortement inspirée par le MOOC Agile de Bertrand Meyer.

Le manifeste Agile

il date de février 2001!

Les 17 auteurs

Les plus connus :

  • Ward Cunningham (Wiki)
  • Kent Beck (XP, JUnit)
  • Ken Schwaber et Jeff Sutherland (Scrum)
  • Alistair Cockburn
  • Martin Fowler
  • …​

Les 12 principes

 

Vous trouverez une version actualisée des principes sur Wikipedia :

 

  1. Customer satisfaction by early and continuous delivery of valuable software
  2. Welcome changing requirements, even in late development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Best architectures, requirements, and designs emerge from self-organizing teams
  12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

Exercice

Repérez dans la liste des 12 principes :

  • Lesquels n’en sont pas!
  • Lesquels sont en fait des pratiques
  • Lesquels sont en fait des assertions
  • Lequel est même erroné
  • Les répétitions inutiles
  • Où est-ce qu’on parle du test?

Correction

Les valeurs agiles

Idées générales, qui précèdent aux principes.

 

Du manifesto lui-même :

  • Les individus et leurs interactions plus que les processus et les outils
  • Du logiciel qui fonctionne plus qu’une documentation exhaustive
  • La collaboration avec les clients plus que la négociation contractuelle
  • L’adaptation au changement plus que le suivi d’un plan

Ne pas oublier la petite phrase qui va avec :

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
http://agilemanifesto.org/

 

  • Nouveau rôle pour le manager (rôle réduit)
  • Pas d’étapes trop tôt ou trop importante (longues)
  • Développement itératifs (et donc continu)
  • Nouvelle façon de négocier (trade off)
  • Focus sur la qualité (et donc les tests)

Les principes

Plusieurs types :

  • Organisationnels / Managériaux
  • Techniques

Les bons principes NON AGILES!

  • Process, procédure et méthodes (critique ⇒ statique, imposée, ruptures entre phases)
  • Insister sur les exigences et leur qualités (critiques ⇒ ils évoluent, on ne les livrent pas, ils sont souvent des solutions plus que des besoins)

Les principes organisationnels

  • Le client au centre
  • Accepte le changement
  • Laisser l’équipe s’organiser
  • Maintenir un rythme durable

Les principes organisationnels (suite)

  • Produire du logiciel "minimaliste"

    • Les fonctionalités requises
    • et uniquement elles
    • ne développer que le code et les tests

YAGNI: You Ain’t Gonna Need It

Les principes techniques

  • Développer itérativement
  • Mettre en avant les tests (TDD)

    • Non regression
    • Test first (TDD)

  • Exprimer les exigences comme des scénarios

    • User stories

Les rôles

  • Product Owner
  • SCRUM Master
  • Team
Mais où est passé le chef de projet?!

Exercise

Quels sont les rôles classique d’un chef de projet?

Eléments de réponse…​

(tirés de Agile MOOC)

  • Définir les objectifs
  • Définir les deadlines
  • Assigner les tâches
  • Servir d’interface avec le management
  • Servir d’interface avec le client

Eléments de réponse…​ (suite)

  • Valider les exigences
  • Décider si les objectifs ont été atteints
  • Faire respecter les deadlines
  • Coacher, mentorer, …​
  • Faire respecter les règles et la méthodologie
Dans Scrum ⇒ pas de chef !

L’auto-organisation (dans l’équipe)

  • Spécialistes mais pas que
  • Transversalité : n’importe qui peut prendre n’importe quelle tâche
  • Sélection collective des objectifs pour l’itération
  • Affectation collective des tâches
  • Démonstration collective des résultats

Product Owner

  • Interface avec le client
  • Défini les caractéristiques du produit (features)
  • Priorise les features
  • Participe aux présentations du produit

Scrum master

  • S’assure que l’équipe applique correctement la méthode
  • S’assure que l’équipe est fonctionnelle
  • Facilite la coopération
  • Protège l’équipe
  • Aide à résoudre les problèmes et blocages

Les pratiques

  • Plannings
  • Meetings & Scrums
  • Retrospectives
  • TDD

Plannings

  • Planning poker
  • Scrum of Scrums
  • Storyboards

Meetings

  • Daily meetings

    • Matin généralement
    • "Stand-up" (<15')
    • Tout le monde participe
    • Engagements/Empêchements

  • Planning meetings

    • Sprint Backlog

Meetings (suite)

  • Retrospective meeetings

    • Qu’est-ce qui a marché?
    • Qu’est-ce qui peut être amélioré?

  • Review meetings

    • On implique le client

Focus sur le Daily meeting

Les 3 questions classiques :

  • Qu’as-tu fait hier?
  • Que vas-tu faire aujourd’hui?
  • Vois-tu des obstacles à venir?

Développement

  • Pair programming
  • Mentor
  • Une seule base de code (vs. branching)
  • Code partagé
  • Garder l’optimisation pour la fin
  • Conception simple
  • Conception incrémentale
  • Refactoring

Release

  • Tôt et souvent
  • Continuous Integration
  • Petite, Incrémentale
  • Cycles hebdomadaires

Tests

  • Utiliser les standards
  • Systématiser les Tests Unitaires
  • TDD

Les artefacts

  • Product Backlog
  • User stories
  • Sprint Backlog
  • Burdown

Product Backlog

  • Propriété du Product Owner
  • Maintenu et "vivant" tout au long du projet
  • Ouvert
  • Contiens des backlog items
  • Inclue des estimations des business values
  • Inclue des estimations des efforts de développement

User stories

As a

…​

I want to

…​

So that

…​

User stories (cards)

User stories vs. UML Use Cases

User stories (ctd.)

Bonne pratique (XP ⇒ INVEST):

  • Indépendante des autres histoires d’utilisateur (dans la mesure du possible)
  • Négociable (discutée avec l’équipe, notamment lors de l’estimation)
  • source de Valeur (porteuse d’une valeur client)

User stories (ctd.)

  • Estimable (elle peut être estimée par l’équipe)
  • (S)Courte (généralement une ou trois phrases environ)
  • D’une Taille appropriée (pouvoir être développée et testée au sein d’une itération)

User stories (suite)

Attributs :

  • Un numéro (Id)
  • Une importance/priorité client
  • Une estimation du coût (en points, temps, …​)
  • Une expression de la forme "En tant que …​ je souhaite …​ pour pouvoir …​

User stories (suite)

Story mapping

Une activité populaire consiste à organiser les Stories sous forme d’une matrice et non d’une simple liste : c’est le Story Mapping.

Must, Should, Could, Wont ⇒ MoSCoW

 

L’autre dimenstion de la matrice :

  • par flot (par dépendances entre stories)

Storyboard

Vélocité

Attention, ce n’est pas une vitesse!
  • Number of items delivered
  • Burndown chart

Sprint Backlog

Juste un regroupement de User Stories, prisent dans le Product Backlog et traitées pour ce Sprint là.

Burndown

Le déroulement

Ready for a quizz?

tuxteacher

 

QUESTION
  • Connectez-vous sur : http://www.socrative.com/ (student login)
  • Ou téléchargez l’application pour étudiant socrative2
  • Choisissez la room 44918d67

/